SharePoint 2010 : Collaboration and Portals - Choosing to Use Portal Sites

SharePoint 2010 provides the same site template and features for both. The difference is in how WCM sites are utilized as compared to a departmental or project portal, for example. Specifically, in the following sections you will learn about how portals are used internally as an accompaniment to collaboration sites. You will review some scenarios in which you might choose to use a publishing portal internally to complement collaboration, how to orchestrate the movement of content between collaboration sites and their associated portals sites, and what features are included within a publishing portal site.

1. Portal Site Scenarios

There are many possible scenarios in which you could elect to use a publishing portal site collection as part of a larger multiteam or multifaceted collaboration implementation. To understand why you would want to use a publishing portal, you first need to review and understand three primary capabilities offered by SharePoint 2010.

• Collaboration Information you want to create and share among a team

• Publishing Provides access to finished information you want to disseminate to others

• Records Management Information you want to keep as evidence of your activities or for future purposes.

It’s important to understand each of these capabilities and how they fit together in the design and implementation of an information management solution.

1.1. Collaboration

Of course, most of the heavy action occurs within the collaboration sites, where team members frequently create new information and work on collateral material together towards a common end goal. This activity might manifest itself in the form of tasks, calendar events, or—as is most common—documents. A hallmark of collaboration sites is the monumental mess that often occurs there as a result of collaboration activity. Everything needed by the team to be successful, from reference materials to the document deliverables themselves, resides in these sites. These sites also tend to have loose governance in that they are largely arranged and organized in real time by the team in a way that best meets the individual team’s needs. It’s a common misconception that collaboration sites should be heavily governed so that people external to the team would be able to easily locate and consume information. The reality is, in a proper implementation of the technology, these external people wouldn’t have access to these sites in the first place, but would instead consume information from an associated portal site. Ideally, the only people who need access to a team collaboration site are the people on the defined team. Letting other sponsors or concerned parties into such sites tends to create more confusion than anything else, as those parties don’t share the information context shared by the team itself. Consequently, these external viewers don’t know which information is the latest and most relevant, and they can become confused and frustrated by all of the supporting material they must sift through to find whatever it is they are looking for. Allowing these external people into collaboration sites also can potentially stifle the collaboration activity, as the team members become all too aware that someone external to the team is looking over their shoulders, causing team members to become concerned about those people possibly making conclusions based on incomplete information.

1.2. Publishing

Publishing portal sites tend to be heavily governed, with a well-defined structure and information taxonomy. Because these sites have a highly controlled authorship and a wide viewing audience, this level of control is necessary to ensure that the information presented is easy to locate, meaningful, and ready for consumption. Often the small groups of people authoring content to these sites are designated team members or team leaders from the associated feeder collaboration sites, in addition to the communications people who ensure uniformity and consistency across the site.

1.3. Records Management

SharePoint 2010 provides a highly flexible set of features for managing the identification and archiving of record information. This information might be key document deliverables as moved through the content life cycle or other record information such as expenses, photographs, or communications between team members and external partners. Each organization defines and handles record information in accordance with its defined policies and procedures. In smaller collaboration implementations, the records management and archival functionality may or may not be used. As with most implementation decisions, an organization’s specific requirements will determine whether this capability is ultimately needed.

Figure 1 illustrates how these three important capabilities included within SharePoint 2010 work together.

1.4. Project Implementation Scenario

Consider that you have an implementation request for a large internal project. The project team consists of the following five well-defined teams, and each team has designated roles within the larger project.

• Design team

• Engineering team

• Communications team

• Testing team

• Implementation team

Each of these teams includes multiple team members. Assume for the purposes of this example that each team has 15 members. Also assume that there are external parties associated with the project, such as project sponsors, internal customers, and business representatives. As the project moves through its phases, more and more documentation deliverables will be created and published for these external parties to review. Additionally, these individual teams themselves will need a common area to exchange information that is relevant across the entire project, such as project level risks and issues, key milestone dates, and overall project status.

A common implementation mistake when working with these sorts of requirements is to attempt to satisfy them all within a single portal site collection. Although this might seem initially attractive because it implies simplification, the long-term effects can be potentially disastrous, especially in larger project scenarios. To understand why, let’s review a few of the disadvantages associated with a single-site collection approach. This approach creates a single, super-massive site collection that

• Places lots of information that must be independently secured, requiring the breaking of security inheritance.

• Often results in inadvertent access to information owned by others.

• Creates potential capacity problems as content databases swell under the load of a super-massive site.

• Expands the failure footprint and effect of a technical problem within the site collection to all users of the project and their information.

• Makes it difficult to expose the appropriate information to other parties.

A preferred implementation approach would be to have separate team collaboration site collections for each of the five project subteams, with an overarching portal site collection for the published materials. The advantages of this approach include

• Each team collaboration site collection is administered by the content owners or their delegates.

• The portal site contains the information that is ready for consumption by third parties.

• Only the portal site is open to third parties.

• The portal site is accessible to all team members, allowing for information common to the entire project to be tracked cohesively.

• Subteam members do not have access to the in-progress information of other subteams, unless such access is needed and explicitly provided.

• Multiple site collections are far easier to manage from a capacity perspective.

• Information published to the portal can be processed through an approval workflow to ensure that it is ready for consumption by the larger group.

Figure 2 illustrates how this type of implementation can work.

2. Publishing Portal Features

When a publishing site is created, you will notice that the site comes with additional functionality that doesn’t exist within standard collaboration sites. Functionality for authoring and editing pages, managing content approval and deployment, as well as enhanced rich text editing functionality and style control, all become available. Additionally, libraries are created for managing pages, site assets, and site collection level styles and images. Table 1 describes these publishing features in detail as they are described within the Feature Management user interface.

You would not want to have these features enabled in team collaboration sites, because the additional functionality could potentially confuse users as well as hamper the collaboration process, which ideally would not employ the level of governance exposed by these additional features. Although these features can be enabled with any site collection, it’s generally a good practice not to turn them on everywhere by default. This is why SharePoint 2010 doesn’t enable them within all site types. In SharePoint Server 2007, there was a site template called a Collaboration Portal. This site type is noticeably absent from SharePoint 2010. This is an effort to guide customers into keeping collaboration and publishing separated. By doing so, each capability is optimized, performs better, and best complements the other.